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SUMMARY 



Tne purpose of this report is to provide a functional design 
specification for a SPLICE Local Area Network which can be used as a 
baseline for developing the detailed system design. The features of 
this design, and the points which we recommend for FMSO and NAVSUP 
adoption in SPLICE, are the following: 

0 Generalized functional modules (e.g., Terminal Management) for serving 
all applications vice designing and programming individual applica- 
tions. 

0 Related to the above point, is the di fferentiation among applications 
at the human-machine interface, i.e., at the terminal display and hard 
copy output. 

° Virtual LAN design approach which places emphasis on the functional 
requi rements of the LAN and later maps to the best pnysical imple- 
mentation for achieving the functional requirements. 

0 Communications protocol within each LAN which only contains the 
complexity necessary to support intra LAN communication and which 
interfaces to the Transmission Control Protocol and the Internet 
Protocol for inter LAN communication, i.e., over the Defense Data 
Network. 

° Virtual ous structure for communication between functional modules and 
distributed, as opposed to centralized, system control. 

° Flexible screen and report format management achieved through user- 
provided screen and report designs. 

° Virtual terminal protocol for achieving independence from specific 
terminal characteri st ics. 



viii 



° Geographically distributed data base management for inter-LAN trans- 
actions but centralized data base management for intra LAN i nteractive 
transactions, using the concept of a specialized file server module as 
opposed to a data base machine. There will be a form of distribution 
existing on each LAN due to tne separation of batch oriented main 
frame dbms from interactive dbms operating in SPL ICE mi nic omputers. 
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INTRODUCTION 



As a result of the growing demands for automated data processing at 
the Navy stock points and inventor control points, long range plans are 
being developed around the Stock Point Logistics Integrated Communica- 
tions Environment (SPLICE) concept. This report provides a design and 
implementation strategy which is based on a distributed architecture for 
a Local Area Network (LAN). The feasibility of a distributed LAN has 
been shown in various applications [1]. 

SPLICE is designed to augment the existing Navy stock point and 

inventory control point ADP facilities which support the Uniform 
Automated Data Processing System - Stock Points (UADPS-SP). The 

hardware for the UADPS-SP consists of the Burroughs medium size 
( B-3500/3700/47 00/ 4300 ) systems. At present there are twenty new 
application systems being developed which require considerable inter- 
active and telecommunication support. The current UADPS-SP cannot 
support these requi rements without a total redesign effort and will 

probaoly require future replacement of the current mainframes. At 
present, project managers are developing the new application systems 
utilizing a variety of minicomputers which are capaole of supporting the 
required interactive and telecommunication capabilities. This is being 
done due to the near term needs of the Navy and are scheduled to oe 
implemented within the next four to five years. There are two major 

objectives behind the development of SPLICE. First, there is the 

i ncreased need for the use of CRT display terminals to interact with 

application logic and to fetch information r rom the system data base. 
Second, there is the need to standardize the multitude of interfaces 
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currently existing across approximately sixty supply sites. 
Standardization of processors is desired to help reduce the overall 
costs of the SPLICE system with regard to processor and telecommuni- 
cation support. The SPLICE processors will be co-located with the host 
Burroughs system at each Navy Stock Point (SP) and with the Burroughs 
and Univac systems at the Inventory Control Points (ICP's). SPLICE is 
to provide economical and responsive support capabilities for a distri- 
buted telecommunication envi ronrrent. A "foreground/background" concept 
will be implemented with SPLICE minicomputers, which will serve as a 
f ront-end-processor for the Burroughs systems via a Local Area Network 
(LAN) interface. The Burroughs computer will provide background 
processing functions for large file processing and report generation. 
SPLICE will be developed using a standard set of minicomputer hardware 
and software. This standardi zation is particularly important when 
considering the fact that SPLICE will be implemented at some sixty 
different geographical locations, each having a different mix of appli- 
cation and terminal requirements. Additional ly , each LAN must have the 
capability of communicating with other LANs via the Defense Data 
Network (DDN) , which is to be provided by the Defense Communications 
Agency. 
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DESIGN APPROACH 



We take the approach of designing the logical or virtual Local 
Area Network (LAN) first, specifying all the functional modules, their 
characteri sties and the communication protocols, rather than focusing on 
the hardware characteristics of LAN first. This is done so tnat we can 
ensure, within the hardware and software constraints of commerci al ly 
available networks, that functional requirements are satisfied. In a 
later phase of this project the virtual LAN requirements will be mapped 
onto a physical local network. The reverse process - starting with a 
physically defined local network (e.g. , CSMA/CD) and working toward the 
virtual LAN - could result in a dysfunctional LAN. The risk, of course, 
in our approach is that, after defining the logical LAN, we may find no 
existing physical LAN which suffices. If this were the case, it would 
indicate that the available physical LANs are infeasible for the SPLICE 
application. It is not anticipated that this will be the case. 
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FUNCTIONAL MODULES 



A functional module is one which provides a generalized function 
for many applications (e.g., terminal management, data base management). 
Ratner than n sets of application modules, there will be one set of 
functional modules which will provide services for n applications. We 
consider this concept a key idea in our design approach and one which 
would save FMSO considerable time and money in system development and 
implementation. The traditional approach to system development involves 
designing and implementing application modules for each application. 
This is a wasteful approach because many functions (e.g., edit, data 
base management, report generation, etc.) are common to many applica- 
tions, resulting in a great deal of redundant system analysis, design, 
programming, coding, testing and maintenance. This approach also causes 
a significant increase in the use of computer resources - memory and 
file storage space. It is primarily tne input and output formats and 
application parameters (e.g., time of printing a periodic report) which 
differ among applications and not the basic operations of editing data, 
maintaining files and generating reports and displays. Figures I and 2 
show the traditional and generalized approacnes, respectively. The 
generalized approach is emphasized in tne design of the LAN. 
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Fiqure 2 . . . Generalized Approach to System Development 



OVERVIEW OF FUNCTIONAL SOFTWARE MODULES AMD 



DESIGN OF VIRTUAL LOCAL AREA NETWORK 



In accordance with the previous two sections in which the ideas of 
virtual LAN design and use of functional nodules were mentioned, this 
section provides an overview of the services provided by various functional 
nodules f Table 1) and the net.hod of providing communication among these 
modules (Figures 3-5). A bus oriented architecture, as shown in Figures 
3-5, has been successfully employed in many LANs r ?,3]. There are also 
more commercially available implementations of this architecture than there 
are for the competing ring and star configurations. 
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TABLE 1 



Functions of Software Modules 



1. Local Communications (LC) 

° Bus arbitration, i.e. , traffic management 

° Message transmission and reception including buffer management 
° Message control (e.g. , error detection, correction and acknowledgement) 
° Administration 

- Message accounting 

- Lost or misdirected message nandling 

- LAN recovery and shutdown 

2. National Communications (NC) 

° Conversion of Defense Data Network protocol to LAN protocol and 
vice versa 

° Message assembly/di sassembly 

3. Front-End Processing (FEP) 

° Terminal and communication line buffering 
° Code conversion 
° Byte/word assemDly/di sassemb ly 

4. Terminal Management ( TM) 

° Message editing 

° Screen management 
° Virtual terminal operations 
. Data 3ase Management (DBM) 

° File creation 
° File update 

° Query processing and data retrieval 
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° Data dictionary creation and maintenance 
° File catalog creation and maintenance 

6. Sess ion Serv ices (SS) 

° Establish and maintain local and remote sessions: 

- Within the LAN (SPLICE minicomputer processes) 

- With local host(s) (mainframe processes) 

- With remote host(s) (mainframe processes) 

° Provide logical and physical network addresses based on value of 
Sen/ ices Request Code. 

7. Peri pheral Management (PM) 

0 Management of Unit Record Input/Output 

- Read a card 

- Pri nt a 1 i ne, etc . 

- Spool files for input and output 

0 Optical Character Recognition or Mark Sense Equipment 

8. R esour ce A1 1 ocati on (RA) 

0 Allocation of shared resources to functional modules 

- Record keeping concerning allocation of shared resources 

- Locating, accessing and making shared resources (e.g., 
memory, disk) available to functional modules 

With regard to TABLE 1, items which warrant elaboration are the 
fol lowi ng: 

° Protocol conversion is provided in the National Communications Module 
because the LAN does not need, and would be slowed down by, the many 
layers of protocol which are required on the DON. 
o Virtual terminal operation refers to the capability of using a variety 
of terminals in SPLICE and converting these terminal protocols to a 
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standard network Virtual Terminal (NVT) protocol for message transfer 
on the LANs and DON, with conversion from the NVT protocol to the 
protocol of the remote terminal or host. This feature is included on 
the assumption that a variety of terminals will be used in SPLICE and 
that it would not be possible to standardize on terminal hardware. 

° Data 3ase Management includes a data base management package which 
would provide languages for file creation, maintenance and query in 
support of all SPLICE applications, consistent with the generalized 
approach to system development shown in Figure 2. 

° Session Services provides for a session to be established by a 

terminal user with any process in SPLICE, wnether it oe a local or 

remote process, within the constraint of access authority. 

° Peripheral Management includes provision for optical character 

recognition or mark sense equipment in anticipation of possible use 
of source entry forms (e.g. , stock requisition form) as an 
alternative to masses of supply clerks keying transactions into 

terminals. This alternative is related to the idea that most users 
will want to have hard-copy of their requisitions; tnerefore, when 
the requisition is typed, it could be typed in a format and font 
acceptable to OCR computer input. 

Items which should oe highlighted in Figure 3 are the following: 
0 Modules are divided into two main categories: operating functions, 
i . e. , transaction processing modules anc support nodules, i.e. , those 
that exist to make effective use of the processing modules and the 
entire LAN. 

Conceptually, the logical design provides two types of ousses: a data 
bus for transferring the actual application messages and a control 
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bus for carrying administrative traffic (e.g., resource allocation and 
error messages). Although a physical design of this type would be highly 
desirable from user and system effectiveness standpoints, because it would 
reduce congestion of user data messages, few local networks available from 
vendors provide separate data and control busses because of the additional 
hardware and cost. 

° "Resource Status Table" refers to tables where shared resources 

availability information (e.g., memory, disk) will be stored. As 

opposed to Figure 3, which shows the logical network concept, Figure 4 

shows a typical three minicomputer LAN physical configuration. Host 

computers refers to existing and future main frames at SPLICE sites. 

Terminals would be interfaced to the FEP from both local (e.g., NSC 

Oakland) sources and satellite (e.g., NARF Alameda) sources. Associated 

with the NC module is the Transmission Control Protocol (TCP), and the 
Internet Protocol (IP), the DOD standard transport protocol and network 
protocols, respectively. 

0 Figure 5 shows that a user task could involve message flow between a 
terminal and a locally connected functional module or between a terminal 
and a remotely connected (e.g., ICP) module. In the latter case, an 
outgoing message (12) would go through the NC module for conversion to 
the format required on the DON. Conversely, an incoming message (02) 

would have its format converted to an LAN compatible pattern before it 

is displayed to the terminal user. In both cases, messages undergo 

processing by the FEP for buffering and message assembly/disassembly and 
by the TM module in order to provide presentation services to the user. 

In the case of a message internal to a LAN (11, 01), the message does 

not flow through the NC module. However, it does undergo processing in 

the FEP and TM modules in the same manner as for DON messages. 
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Operating Functions 
Implemented in Software Modules 
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Figure 3 . . . Local Network Logical Connections 
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Figure 5 . . . Logical Flow In Local Area Network 



LOCAL COMMUNICATIONS (LC) MODULE 



In the description which follows, "Sender and "Receiver" are generic 
names of a module which sends a message and the module which receives the 
message. The LC module will have the following properties: 

° Acknowledgement of individual messages, i.e. , only one message at a 
time will be outstanding between a pair of functional modules. 

° Standard message format will nave a place for acknowledgement. 
Whenever possible acknowledgements will be piggybacked onto a message 
travelling in the reverse direction. Upon receipt of positive 
acknowledgement, the sender will release the acknowledged message's 
buffer space. Upon expiration of a time out, the sender will 
re-transmit message. Retransmission will be repeated once, if the 
first retransmi ssion also fails. If the second retransmi ssion fails, 
the sender will notify the Recovery Management (RM) Module of the 
existence of an error condition between the relevant pair of physical 
nodes and the relevant pair of modules. The sender will send no more 
data to any module and the receiver will not process data from any 
module until notified by the RM that the error has cleared. 

° Messages will be transmitted in one continuous stream of bits, i.e., 
messages will not be split into packets. This will simplify the 

communications protocol. This will require buffer space to be reserved 
for the maximum size message. However, buffer size requirements will 
tend to be reduced because no more than one message will be 
unacknowledged at a time. Ho message greater than the maximum size 
message will be transmitted by a module. In the rare case where a 
message is larger than the maximum size message, it will be broken into 
two or more smaller fragments. 
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It will be possible to set up a virtual circuit between any two modules 
(Figure 6). We don't say between any two nodes because a node could 
contain two or more modules. The virtual circuit would be implemented 
by creating tables in the Session Services Module at the sending and 
receiving ends of the connection. 

The following types of communication will be possible (Figure *) : 

LAN 

Foreground 

Virtual circuit between two functional modules residing in SPLICE 
minicomputers (e.g., virtual circuit between Terminal Management and Data 
Rase Management Modules) 

Background 

Virtual circuit between a functional module residing in a SPLICE 
minicomputer and a functional module residing in a main frame (e.g.. 
Terminal Management Module and Burroughs OBMS) 

DON 

Foreground 

Virtual circuit between a local functional module residing in a SPLICE 
minicomputer and a remote functional module residing in a SPLICE minicom- 
puter. 

Background 

Virtual circuit between a local functional module residing in a SPLICE 
minicomputer and a remote functional module residing in a main f rame. 
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Figure 6 . . . Virtual Circuit Possibilities 



Addressing 



In order to implement the architecture which has been suggested, it 
will be necessary to assign logical addresses to the various functional 

modules which will be contained within the SPLICE minicomputers and to 
the functional modules which currently exist in the SP and ICP main 
frames (e.g. , Burroughs computers). The latter requirement will 
necessitate identifying which programs or packages in the main frames 
(e.g., data base management) consitute functional modules. Furthermore, 
it will be necessary to create and maintain a table which will return 

the physical address of a hardware unit when the logical address is 

provided as an argument [4]. This table and the associated maintenance 
functions will be the respons ibi 1 i ty of Session Services. The use of 
logical addresses will allow mobility of functional modules, i.e. , it 
will be possible to relocate a functional module to a different hardware 
unit when required for performance or recovery purposes. 

Network Layers 

For sending and receiving messages on the DON, all layers of the 

ISO model will be used, as shown in Table 2. The Oata Link and Physical 
layers are shown unspecified in Table 2. The LAN has no need for the 
services normal ly provided by the Transport and Network layers. 
Additionally, the application layer is shown for the purpose of complete- 
ness; it has no effect on inessage handling within the LAN. The 
Presentation layer, implemented in the Terminal Management Module, will 
accept data from the application process and convert it to the standard 
LAN format. Conversely, it will accept messages in standard LAN for;rat 
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and convert them to the appropriate application process format. A terminal 
user is considered to be one of the "application processes". 

For the purpose of simplifying the LAN design and in view of the fact 
that intra LAN communication does not require all seven ISO layers, but DON 
communication does require all layers, the following message formats will be 
used: 

° TCP format [5] will be provided to the DDN by the NC module (described 
in the next section) whenever communication on the DDN is necessary. A 
much simpler format, as shewn in Figure 7, will be used for intra LAN 
communication [14]. 

0 End to end virtual circuit connections and breaking of complete messages 
into fragments, services normally provided by the transport layer, will 
be implemented in each of the functional modules. "End to end" in this 
context refers to the logical communication linkage between two modules 
which are separated by a relatively short distance; in some cases, the 
two modules could be in the same hardware unit. The above approach is 
considered to be the best solution to the dilemma of whether to include 
TCP in the LAN communication. If it were included, functions which are 
not needed, (e.g. , flow control) would be implemented unnecessarily. On 
the other hand, if we were to modify the SS layer to incorporate these 
needed TCP functions, the LAN SS Layer would differ from the SS Layer 
which is needed for the DDN (where the complete TCP is utilized). It is 
appropriate to use a subset of the DDN virtual circuit protocol which is 
as close to the long haul network protocol as possible, rather than 
design two separate protocols [13]. This approach makes translation 
between the two protocols easy and provides for protocol compatibility. 
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Table 2 





Use of ISO Layers in LAN Design 
LAN Communication 


Layer 


Mod til e 


Application 


Application process modules 
(e.g. , APADE, IDA)* 


Presentation 


Terminal Management 


Session 


Session Services 


Data Link 


Local Communications 


Physical 


Local Communications 
DDN Communication 


Ap pi icat ion 


Same as for LAN 


Presentation 


Terminal Management 


Session 


Session Services 


T ransport 


TCP 


Network 


IP 


Data Link } 


Specified by the DDN 


Physical ) 





* Application processing and data base management should oe 
incorporated into the functional modules (e.g. , Terminal 
Management and Data 3ase Management) as much as possible. 
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Message Formats 



Intra LAN message formats are illustrated and defined in this section 
(Figure 7). LAN message formats have been suggested by many authors 
including [5]. Acknowledgements will be piggybacked onto data messages 
whenever data is ready to send to the module which requires an acknowledge- 
ment (Figure 9). In those cases where there is no da ta to transmit, an 
"ordinary acknowledgement" will be used (Figure 8). This procedure 

requires provisions for identifying both new messages and acknowledged 
messages. In order to account for the possibility of a long message which 
exceeds the maximum buffer size of a functional module, the concept of 
"fragment" is used. A fragment is simply part of a message. This tech- 
nique requires identification numbers for both messages and fragments, for 
new messages and acknowledged messages (Figure 7). 
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Flag 

Message Type 



Date and Time 



Destination ^Ad dress 
Logical } Physical 



S_o u £_c e_ Ad d re sjs 
Logi cal Physical 



Number of Fragments 



Message Number 



Fragment Number 



Acknowledgement Message Number 
Acknowledgement Fragment Number 



Data Length 



Se rvi ces 
Request Code 



Data 



Error Check 



FI ag 



I Used for data message and 
i non-piggybacked acknowledgement. 

I Only used when acknowledgement 
\ i s piggybacked onto data. 



! Only used when data is sent. 



Note: All fields are fixed length except data portion. 



Figure 7 . . . LAM Message Format 
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Flag: Bit pattern which signifies the beginning and ending of a message 

fragment .* 

Message Type: Code indicating type of message: 

- Normal Data (FIFO) 

- Priority Data 

- Ordinary Acknowledgement (Figure 3) 

- Data with Piggybacked Acknowledgement (Figure 9) 

- Reset LAM (Reset LAN cominuni cat ions after error condition. 
Purge messages in transit. Reset message counters to zero.) 

- Reset message and Fragment Counts (Reset counters to zero.) 

- LAN shutdown 

- etc. 

Date and Time: Day, month, year and 24 hour clock time of transmission from 

se nder. 

Destination Address: Logical and physical addresses of sending module. 

Source Address: Logical and physical addresses of sending module. 

Number of Fragments: Number of fragments contained in a message. Used for 

message sequencing and acknowledgement control and by 
the receiver for allocating buffer space. 

Message Number: Sequential number assigned to each transmitted message. In 

the case of an acknowledgement, the number of the message 
being acknowledged is placed in this field. The number is 
reset to zero periodically. Each module will De 
responsible for setting, incrementing and resetting this 

* A fragment is either an entire message or part of a message which is too 
long to transmit as a single entity. 
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count. Thus the receiver will know which message number it 
should receive next and the sender will know wnich nessage 
number should be acknowledged next by the receiver. 

Fragment Number: Sequential number which is assigned to each fragment 
comprising a message. This number is reset to zero by the 
sender when the first fragment of the next message is to be 
transmitted. Each .module will be responsible for setting, 
incrementing and resetting this count. Tnus the receiver 
will know which fragment number it should receive next (Tne 
message number should increase after all fragments have 

been received). The sender will know wnicn fragment number 

should be acknowledged next by the receiver. The first 
fragment will be numbered ft. 

Acknowledge Message Number: Message number that is being acknowledged. 

Acknowledge Fragment Number Fragment number that is being acknowledged. 

Data Lenth. Number of bytes contained in the data portion of a 

fragment. This value can be zero. 

Services Request Code: Code which indicates which service (e.g. , retrieve 

record) is desired by a process (e.g., use'' task). 

Data: User or control data. 

Error Check: CRC code computed by sender. If an error is detected by 

receiver, the r ragment is discarded by receiver and no 
acknowledgement is sent to the sender. After appropriate 
time-out, sender will retransmit. If this attempt 'nails, 

the Recovery Management (RM) module is notified of tne 
existence of an error condition. 
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Ordinary acknowledgement 



Flag 

Message Type 

Date and Time 

Destination Address 

LoaicaX T ‘""PhvFicaT " 
Source Address 
LogicaX T ~°hysicaX " 

Number of Fragments 
Message Number 
Fragment Number 
Error Check* 



Flag 



Date and time acknowledgement transmitted 

Logical and physical address of sender 
Logical and physical address of receiver 

H ^ »» 

Original message values 



Note: In an ordinary acknowledgement, the roles of "sender” and "receiver” 

are reversed, as shown below. 




* CRC code computed by receiver. If error detected, sender resends 
fragment. Receiver has duplicate fragment detection capability. If 
duplicate detected, it is discarded/ acknowledged and original fragment 
is processed. 



Figure 3 . . . Ordinary LAN Message Acknowledgement 
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Flag 


Message Type 


Date and Time 


Destination Address 
Loaical \ Physical 


Source Address 
Logical \ Phvsical 


Number of Fragments 


Message Number 


Fragment Number 


Acknowledgement Message Number 


Acknowledgement Fragment Number 


Services 

Data Length Request Code 


Data 


Error Check* 


Flag 



Acknowledgement piggybacked 
onto data 

Date and time data and acknowledge- 
ment transmitted 

Loqical and physical address of sender 
Logical and physical address of receiver 



Message number of data 

Fragment number of data 

Message number of data being 
acknowledged 

Fragment number of data being 
acknowledged 



Note: In a piggybacked acknowledgement, the roles of sender and receiver 

are as shown below. 



Receiver 


Ack. to Msg. 91 

^ i — 


Sender 


(checks 


^ Msg. #2 


(computes 


CPC code) 


< 2 1 


CRC code) 



* CRC code computed by sender. If error detected by receiver, it will 
discard fragment and retransmit message 91 after appropriate time out. 
Sender will detect duplicate, discard it, transmit acknowledgement and 
use original fragment. Sender will retransmit message #2 after 
appropriate time out. 



Figure 9 . . . Piggybacked LAN message acknowledgement 
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Control and Data Busses 



As shown in Figure 3, there are logical control and data busses. 
It was mentioned that this virtual architecture probably will not be 
implemented physically. However, it will be implemented logically by 
providing separate ports or addresses in a functional module for 
addressing control and data messages. In addition, each message type 
will nave its own queue and the control message queue will have higher 
priority than the data message queue, i.e. . if control messages exist in 
its queue, all of them will be processed before any data messages are 
processed. T'ne reason for this is that there could be control messages 
pertaining to system shutdown, recovery error conditions, etc. which 
require the immediate attention of the module. The implementation of a 
virtual control bus is in accordance with the principle of separation of 
functions in software design, i.e., grouping like functions in the same 
module. This procedure would allow changes to be made in control 
message functions and formats without affecting data message software, 
and vice versa. Also, the amount of control message traffic could be 
significant. System loading can be alleviated by allocating separate 
queues to the two message types and by physically implementing data 
message and control message ports at the node level with separate DMA 
channel s. 
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NATIONAL COMMUNICATIONS (NC) MODULE 



Very roughly, computer networks can be divided into two distinct types; 
local area network (e.g. , SPLICE LAN) and long-haul (e.g. , DON). 
Increasingly , networks are no longer limited to either type. An emerging 
requirement is to interconnect the two types of networks. As described in 
[7], the interconnection problem may be viewed in terms of interfaces and 
network services. Each of these may be divided according to whether they 
possess datagram or virtual circuit characteri sties. A datagram interface 
allows a user to enter packets into the network independent of other 
packets; each packet will De handled separately. • A virtual circuit 
interface requires that an end to end logical circuit be established between 
source and destination. A datagram service is one in which each packet is 
"on its own"; sequenced delivery or any kind of delivery, for that matter, 
is not guaranteed. Duplicates are possible. Virtual circuit service, on 
the other hand, guarantees sequenced delivery, provides flow control and 
eliminates duplicate packets. 

In the NC module of the LAN, both sides of the interface will provide a 
virtual circuit service. Message fragments are transmitted within a LAN and 
packets are transmitted on the DON backbone. The NC module is responsible 
for providing the interface between each LAN and the DON. In particular, 
this module will provide the conversion between the LAN protocol and TCP and 
vice versa. Instead of connecting all LAN modules and nodes directly to the 
DON, a gateway is provided [7,13]. The NC module, located in the Front-End 
Processor (FEP) , provides protocol conversion and the Interface Message 
Processor (IMP) of the DON, to which the FEP is connected, serves as a 
gateway (see Figure 10). 

Packets which constitute a message from the DDN are accumulated at the 
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NC in a manner similar to that which occurs at the destination IMP in 
ARPANET. A message or fragment (one of the functions of NC is to perform 
message fragmentation on incoming messages, where neccessary) is then sent 
by the NC to the destination module on the LAN. The SS at the originating 
LAN would have recorded the destination module logical address and physical 
address in the message (see Session Services in next section). It will be a 
function of the Network Management (NM) Module located at FMSO to broadcast 
changes in physical addresses to the various LANs. The NM will maintain 
uniqueness of logical and physical addresses by assigning them to the 
various LANs (Recovery Management Modules). (The detailed functions of the 
NM are not covered in this report) . It will be the responsibi 1 ity of the 
Recovery Management (RM) Module in each LAN to maintain the LAN copy of the 
Network Directory, i.e. , make changes to network physical addresses. The SS 
Module will have read but not write access to the directory. 

Physically, NC will reside in the FEP. Unless a message requires 
priority handling, it will send messages to the nearest Packet Switching 
Node (PSN) , or IMP, of the DDN on a FIFO basis. Since the speed of the LAN 
is greater than the DDN, the NC buffer space could become exhausted [7, 13]. 
This will be handled, as in the LC, by only allowing a single message from a 
given Functional Module (FM) , to be unacknowledged at a time and by reserv- 
i ng a buffer space equal to the maximum size message fragment. This 
approach will also have the advantage of providing a uniform method of 
message handling, independent of whether the message is intra or inter LAN. 

Only those aspects of the TCP which are necessary to convert messages 
from LAN to DDN format and vice versa will be implemented in the NC. 
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Brief Description of TCP [5] 



The key characteri sties of TCP are Che following: 

0 Host-Host Protocol (i.e. , end to end protocol) 

° Located in ISO Transport Layer 
0 Guaranteed sequenced message del ivery 
° Logical full duplex connections 
° Sequence number assigned to each octet (3 bits) 

0 Time out used to control message sequencing and acknowledgements 
° Connection name used to refer to connections after the connection has 
been established. This would be the concatenati on of the SPLICE logical 
address (functional module address) and the physical unit address. 

° Users may indicate precedence and security of messages. 

0 Window oriented flow control 
0 Message segments reordered at destination TCP 
0 Acknowledgements required 

TCP Functions Implemented by the NC Module 

The following TCP User Commands will be implemented in the NC , where 
"User" really means "NC". The terminal user will employ a command language 
which TM will interpret and send along to NC when a remote module is to be 
utilized. See Reference [S 1 for a complete description of these commands. 

° 0°EN 

- Attive: Begin procedure to synchroniz° the connection at once. 

- Passive: LISTEN for an incoming connection. 

The local and remote NCs will notify their respective pe r tinent modules 
when a connection has been established. 
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SEND 



- Send data contained in the indicated user buffer on the indicated 
connection. 

° RECEIVE 

- Allocate a receiving buffer associated with the specified connection. 

° CLOSE 

- Close the specified connection 

- The local and remote NCs will notify their respective perti nent modu les 
that the connection has been closed. 

° STATUS 

- Obtain status of connection (e.g., OPEN or CLOSED). According to [5] 
it is not mandatory to implement this command. However, this would be 
a very worthwhile command to implement for SPLICE. 

° ABORT 

- Causes all pending SENDS and RECEIVES to be aborted. A RESET message 
is sent to the remote TCP. The local and remote NCs will notify their 
respective pertinent modules when a connection has been aborted. 

The NC will be able to request network status (e.g., PSNs up/down, 
SPLICE processors up/down, etc.) from the NM which, it is assumed, will be 
able to obtain DON status information from the network management facility 
in the DON. As far as LAN status information is concerned, it will be the 
responsibility of the RM to forward changes in LAM status (e.g., SPLICE 
processor down) to the NM and to all functional modules and processors 
within its LAN. 
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Interpretati on of TCP Address 



The TCP uses a port identifier in its header [5]. The concatena- 
tion of the port identifier with the network and local addresses used in 
the Internet Protocol Message Header constitutes a socket. The Internet 
Protocol is the D00 standard network layer protocol [3]. The local 
socket refers to the identification of the source (process initiating 
connection) end of a connection and the foreign socket refers to the 
identification of the destination end of a connection. After a connec- 
tion has been opened, the local-foreign socket pair may be referred to 
by a connection name. In the LAN, port identification corresponds to 
the logical address of a functional module. The network address and 
local address corresponds to the LAN and physical processor in which the 
module resides, respectively (see Figure 12). As stated previously, 
logical addresses do not change, whereas physical addresses are subject 
to change, allowing for mobility of modules. Both types of addresses 
are necessary in order to access a particular functional module in the 
SPLICE network. 
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Interconnect Between LANs and DON 



As indicated previously there are two basic ways of providing 
communication between two processes: virtual circuits and datagrams. 
The former provides reliable end-to-end communication between a pair of 
processes, with sequenced message delivery and elimination of duplicate 
messages ensured. In order to establish a virtual circuit, as with the 
X.25 Protocol, a set up procedure is necessary [13]. This is the call 
request, which, in the X.25 Protocol, establishes a fixed route between 
gateways (interfaces between two networks) for the virtal circuit; 
routing within the networks which are connected by the gateways may be 
dynamic (i.e. , non-fixed) [11]. Virtual circuits may also be divided 
into the two categories of switched and permanent [18]. The former is 
implemented when the called process accepts the call request issued by 
the calling process. A permanent virtual circuit, on the other hand, is 
always established; hence, it does not require a call-up procedure. 

The datagram form of transmission provides a transaction service 
(e.g. , update a file record) [11]. The Transmission Control Protocol 
[5] of the DDN which corresponds to the Transport Layer of the ISO OSI 
Model [24], provides virtual circuit service [11,19]. The Network Layer 
of the ISO model, as implemented in DDN, will be the Internet Protocol 
[8]. The Internet Protocol will provide a datagram service operating 
under TCP. This concept is shown in Figure 10, where each LAN would be 
connected to the first Packet Switching Node (PSN) of the DDN. As shewn 
in Figure 10, virtual circuits are implemented by placing the modules 
(e.g., Session Services) and protocols (e.g., TCP) at the end points of 
the network [21]. In order to transport a message of the format shown 
in Figure 11 across the DDN, it must first be encapsulated in the TCP 
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header which, in turn, will be wrapped in the Internet header as 
suggested by Figure 11 [21]. This encapsulated data is called a 
datagram. Datagrams exist between points in tne network wnere the 

Internet Protocol (IP) is located, as shown in Figure 10 [20]. The IP 
will examine the network address portion of tne datagram at the gateways 
(see Figure 10) and route it to the destination LAN gateway. Thus the 
IP and its datagram form of communication provide transmission in tne 
communications suDnet (i.e. , DON), whereas TCP and its segment provide 
the end-to-end virtual circuit service. 

Some networks - those employing X.25 and SNA - employ fixed routing 
[23]. This procedure guarantees sequenced message delivery. The DON, 
by using two protocols - TCP in the transport layer and I? in tne 
network layer, can provide virtual circuit service (TCP) without 

requiring fixed routing. The Internet datagram service provides dynamic 
routing so that all datagrams correspondi ng to a given session do not 

have to follow the same fixed route. 

In many networks a distinction is made between application modules 
and their names and frequently accessed server modules (e.g. , file 
server) and tneir names [22]. In the proposed design the "application 
modules" are the server modules (e.g.. functional modules). The 
functional module names are indicated as the logical addresses in the 
message part of the datagram in Figure 12. These addresses are copied 
into the TCP header. The physical node addresses in tne message section 
(See Figure 12) are copied into the Internet header. Because there 

could be more than one FEP and set of physical nodes associated with a 
given LAN, a LAN address and physical node address (tne address of the 
node containing a process) are required in the Internet header. 
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It is the responsibi 1 ity of the National Communications (NC) Module 
in the Front-End Processor (FEP) to yet an incoming messaye routed to 
the correct functional module (FM) on tne LAN when a datayram is 
received over the DON and to prepare an outgoing messaye in the format 
of Figures 11 and 12 for transmission on the DDN. It will also be the 
responsibility of NC to fragment both incoming and outgoing messages, if 
necessary, in order to be compatible with the maximum size buffer of the 
FMs and to reassemble incoming message fragments. Each outgoing fragment 
will be put into the format of Figure 11. 

All acknowledgements over the DDN are done between the FEPs. Once 
a message is delivered to a FEP from the DDN, a one-for-one (i.e. . stop 
and wait) acknowledgement system will oe used between the addressed FM in 
the LAN and the National Communication Module in the FEP Similarly the 
stop and wait acknowledgement method will be used between the source FM 
and its associated FEP on an outgoing message. For botn incoming and 
outgoing messages, fragments could exist and, when this is the case, 
acknowledgements within an LAN will be done on a fragment basis. Once an 
outgoing message fraynent is acknowledged by NC to the FM, it is released 
to be sent over the DDN as a datagram, with acknowledgement of the 
corresponding TCP segment occurring between the source and destination 
TCPs. Similarly, once an incoming TCP segment, wrapped as an Internet 
datagram, has been acknowledged oetween the pair of TCPs, it will be sent 
to the intended FM and acknowledged as a fragment to NC. 
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Figure 10 . . . Relationship Between Local ^rea Networks and Defense Data Network 





INTERNET 

PROTOCOL 

Header 



TRANSMISSION 

CONTROL 

PROTOCOL 

Header 



LAN 

Message * 



# Source/Destination 

LAN (Gateway) Addressing 

• Source/Destination 
LAN Node Addressing 



• Source/Destination LAN 

Process (Functional Module) 
Addressing 



• Source/Destination LAN 
Process Addressing 

• Source/Destination 
LAN Node Addressing 



Complete message or fragment 



Figure 11 . . . Internet Datagram 




IP Header 



TCP Header 



\ 



LAN Message 



) 



3 

\ 

/^Identification: Identifier used By IP to Reassemble All Fragments Belonging to a 
Datagram (Value Provided by TCP) 

Protocol: Identifies Next Protocol Above IP (i.e., TCP) 

Source Network Address : Address of Source LAN 

Source Local Address: Address of Source LAN Physical Node 

Destination Network Address: Address of Destination LAN 



V* 



( 



Destination Local Address: Address cf Destination LAN Physical Node 
Source Port: Source Logical Address 
Destination Port: Destination Logical Address 



Figure 12 . . . Internet Datagram Showing Fields of IP Header, TCP Header and LAN 

Message which are Relevant to Addressing 
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SESSIONS SERV ICES (S S) MODULE 



Figure 13 shows how the Session Services (SS) nodule will be used 
to coordinate the interaction among a user task, TM and another 
functional module (e.g. , DBMS). A services request code in a message, 
corresponding to a user request task, is used by SS to obtain the 
logical and physical addresses of the functional module which will 
perform the requested service. Session Services invokes the appropriate 
functional module which, in turn, accesses the user message in the TM 
buffer. The functional module returns the required data after 

interpreting the instructions in the user message. It is a function of 
TM to present the data provided by the functional module in the format 
desired by the terminal user. The number in the figure corresponds to 
the sequence of steps in the process. It is evident that the following 
ISO layers are involved: 

Application: User request task 

Presentation: Formatting by TM 

Session Services: Invoking the functional module 

Data Link i 

| Message transmission 
Physical > 

It will oe noted that Transport and Network layers are not used. 

Terminal Management (TM) is the primary interface with the user 
process. Session Services coordinates and controls the various 
functional modules (whether on LAN, local hosts or remote hosts) to 
provide the services required by the user process [26]. The functional 
modules act as servers to session services for performing various tasks 
(e.g., data retrieval). Figure 13 shows Session Services operating 
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through TM. This is because user process messages will be resident in 
TM during a session and because TM will keep the terminal user informed 
of the progress of processing his request. Session Services will issue 
various messages to the functional modules, such as "get record x" , 
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Figure 13 . - . Session Services Coordinating Function 




Mail Box Capability 



There is no inherent reason why a terminal user should have to be 
logged on or sit at a terminal through what could be long sessions while 
his data is being processed. There are many operations, usually those 
involving complex data management functions, which are not the short, 
interactive type. For those transactions which do not require continued 
user attention and interaction with the LAM, the transactions will be 
input by the user, and deposited in a mailbox [25]. Physical 

implementation of the mailbox may require disk storage in addition to 
main memory in the minicomputer where Terminal Management is resident. 

Session Services, upon receiving a control message from Terminal 

Management, as depicted in Figure 13, will be responsible for setting up 
a "session" between the mailbox and a functional module (FM). The FM 
will read messages from the mailbox and process them during the time the 
user is logged off. The FM will return any results to the mailbox for 
pick up by the user during a subsequent terminal session. 

It should be noted that either a local or remote FM could be 

involved in either interactive or non-i nteracti ve processing and that in 
some situations it will be necessary for SS to invoke more than one FM 
to process a user task (e.g. , the Data Base Module for retrieving data 
for terminal display and Peripheral Management for producing printed 
output). Also, in general, an FM could be local (e.g., local Data Base 
Module returns data to be displayed on local terminal) and another FM 
could be remote (e.g., locally retrieved data is sent over the DON to be 
displayed via Terminal Management on a remote terminal). 



41 



Multiple Sessions 



The various sessions which can be conducted require a data 
structure for keeping track of these sessions and the functional modules 
(FM) which take part in a session. A tree data structure for this 
purpose is shown in Figure 14. Each time a user request is analyzed by 
SS and it determines which FMs are involved (one or more), a unique 
session number is assigned. The session number will be the mechanism 
whereby SS can determine which modules are involved in subsequent 
message transmissions for a given session and the sequence of message 
transmission and sequence of using the FMs (e.g., record extraction by 
Data Base Management and subsequent print of the record by Peripheral 
Management). The following should be noted in Figure 14. FM can be 
involved in more than one session at a time, involving more than one 
user: 

° A user can have more than one session at a time. 

° A session can involve multiple FMs. 



42 



User 




User 


Identification 




Identification 



Invoked by 
User Call 
For Service 




Session 




Session 




Session 


Number 




Number 




Number 



Invoked 
by Session 
Services 




Functional 

Module 

Name 




Functional 

Module 

Name 




Functional 

Module 

Name 


FMl 


FM2 


FMn 



Functional Module Marne = Logical Address: Assuming Module Names are 
uniquely assigned throughout SPLICE system; otherwise, Network 
Address and Physical Address must be concatenated with Logical 
Address . 



Figure 14 . . Session Services Data Structure 
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TERMINAL MANAGEMENT (TM) MODULE 



As indicated previously, the major design approach is to provide a 
set of functional modules (e.g., data base management) each of which 
will provide the same basic service (e.g., retrieve a record for all 
applications). Using this approach, the place in the system where 
applications are differentiated is the human-machine interface, i.e. , 
the terminal screen formats. In addition to this consideration, the 
Naval Supply System has been plagued by inflexible terminal operations 
with respect to speed, code, format, editing capability, line discipline 
and command language. Furthermore, existing terminals are heavily 
dependent on inflexible vendor (Burroughs) terminal control units and 
most of the terminals cannot be programed for changing I/O 

requirements. Some of these I/O inflexibilities can only be cured by 
obtaining modern terminals and control units, where either or both can 
be programmed. However, equipment alone will not provide a long term 

solution to achieving flexibility of terminal operations. The Naval 
Supply System must not again be in the position of being a "captive" of 
its terminal characteri sties. In order to avoid this possibility, a 
fundamental change in design approach is necessary. Two measures are 
recommended in order to correct current deficiencies. 

1. User Designed Screen Formats 

One measure is designed to provide the user with flexibility of 
terminal screen format. Despite the fact that efficiency of design 
is achieved by generalizing the "application" modules (i.e., 
functional modules), the user naturally wants screen formats which 
are application oriented. Since one of the major lessons which has 
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been learned in data processing is that it is futile to try to 
anticipate user requirements - these frequently evolve in unpre- 
dictable ways - a wise strategy is to provide a capability for the 
user to do a certain amount of the design himself, namely, terminal 
screen design. This is accomplished by the user designing a tem- 
plate of screen format, along with the prompts which are desired. 
At first blush this approach may seem to be imposing an undue burden 
on the user. Further reflection may convince the reader that it has 
the following advantages: 

° It is thoroughly consistent with the idea of providing generalized 
functional modules, i.e. , the screen design feature would be a 
part of the Terminal Management (TM) module ( al ternati vely , it 
could be part of the Oa ta 3ase Management module). As such, it 
would be available to al 1 users and appl ications, as opposed to 
the traditional approach of application programmers designing 
specific screen formats and the supporting programming for each 
application. Our recommended approach shifts the burden of 
providing this software from FMSO to a vendor provided package 
with the required capabi 1 i ti es. As mentioned previously, this 
aporoach is cost-effective because vendor development costs are 
spread across many customers and, in addition, significant 
application design and programming costs, involving the use of 
critical personnel skills, could be avoided by FMSO. 

0 This approach eliminates the usual never-ending effort to upgrade 
user terminal display and report capabilities by providing £ or 
inevitable future change by acquiring, during the acquisition 
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phase, a software package with built-in capacity for change, 



rather than F'iSO having to respond in fire-fighting fashion to 
changing requi regents during the operational phase. Since the user 
becomes responsible for fashioning his own display and report 
formats, he is more likely to be supportive of the system or at 
least is less likely to be critical than would otherwise be the 
case. Both terminal display (screen) and report formats could be 
designed by the user. Incidentally, there is nothing in this 
proposal to prohibit FMSO analysts and programmers from designing 
these formats, should this be desired by FMSO management. 
Obviously, some centralized control over screen and report formats 
which are common to the Stock Points and ICPs is necessary in 
order to prevent the chaos which would result with uncontrolled 
user design of formats. On the other hand, those formats which 
are unique to a Stock Point or I CP could be designed locally. In 
this discussion the term "user" is employed generically and is not 
meant to imply that individual stock clerks, as opoosed to 
supervised user organizations, would necessarily design formats. 

The screen and report formats would be designed, using the 
terminal itself as the medium for specifying the desired formats, 
and stored by the system for subsequent recall by the user when 
performing file update and query operations. A tremendous 

advantage of this approach is the ability to permanently store the 
templates and to add, delete and change fields by using the 
vendor's data definition language, and to add, delete and reformat 
screen and report images by using cursor control formatting 
procedures at the terminal itself. 
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Logically, the vendor provided screen and report format design 
functions are part of Terminal Management and Peripheral Management 
modules, respectively, as defined in this report. However, depend- 
ing upon the design of the vendor's software, these functions could 
be included in a data base management package or the report format 
design function might appear as part of a report generator. Except 
to the extent it affects modularity of design, the packaging of 
functions is essentially immaterial to the subject of this report, 
which is the functional specification of the LAN. 

2. Virtual Terminal Capability 

It has been found in a number of networks [9,10], notably 
ARPANET and European network developments, that a virtual terminal 
concept and its accompanying Network Virtual Terminal (NVT) protocol 
is necessary in order to accommodate a great variety of existing 
terminals in a network and, more importantly, to accommodate future 
terminal requirements. Where there are m hosts and n terminals, the 
resulting m x n problem can be reduced to an m x 1 problem [10] by 

using a standard terminal protocol - the NVT protocol - in the 

network. Each source terminal's characteristics are mapped to the 

NVT, for transmission in the network, and then mapped from NVT to 

the destination terminal's characteristics for presentation at that 
terminal, where "terminal" can be a computer process in addition to 
a physical terminal. Characteristics such as character code, line 
length, page width, print density, etc. are commonly included in the 
NVT. Of course, character istics which are physically unavailable 
(e.g. , specifying a line length of 132 characters on an 30 character 
terminal), cannot be achieved. The user employs the NVT by issuing 
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commands, in the language of tne NVT to "negotiate" source and 
destination terminal characteristics with the remote process. 

The Defense Data Network (DON) will have a ARPANET TELNET NVT 
feature [12]. In addition to the protocol required for LAN screen 

management, the NVT protocol will be a necessary part of the TM module, 
as indicated in Figure 4, in order to communicate with remote processes, 
where other than default terminal characteristics are desired for a 
given operation. 

As indicated in the previous section and in Figure 13, the TM 
module will store user messages in its mailbox for subsequent processing 
by other FMs and will deliver result messages, deposited in its mailbox 
by other FMs, to the user's screen during a subsequent user terminal 
session. 



48 



DATA 8A S E MANAGEMENT (DBM) MODUL E 



This LAN design provides for distributed control, as described in 
the next section, but does not provide for the distribution of data 
bases within a LAN. When viewed over the entire SPLICE system, data 
bases are obviously geographically distributed. For the purposes of 
maintaining adequate control over cataloging files and maintaining tne 
integrity of related files in the data base (synchronization of updating 
procedures), the data base functions are centralized withi n each LAN. 
Other than the fact that some files will remain on the Burroughs Hosts 
and some files will migrate to DBM, there is no reason to provide for 
the distribution of data bases within a LAN. 

File Server 

Processors will be dedicated to data base management (see Figure 
15). It is arguable whether they could be classified as data base 
machines, since they will not have all of the specialized hardware which 
is usually associated with this machine [16]. Also, there is a 
difference of opinion among specialists concerning whether data oase 
machines have achieved technical maturity [17]. The need for 
specialization of data oase functions in the form of special puroose 
hardware, which is central to the design philosophy of data base 
machines, appears to be unnecessary in the case of SPLICE. Rather, a 
"special purpose software module" - a file server - residing in large 
scale minicomputers, witn adequate fixed disk storage for highly active 
files, augmented by larger movable disks for less active files, should 
be adequate for handling foreground queries and file maintenance 
requests [17]. In a very loose sense, the file server acts as a aata 
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base machine, in that all data base processing is off loaded from other 
modules and node(s), and concentrated at a single module and node, but 
without the special purpose hardware of a data base machine (e.g. , data 
base command and control processor, keyword transformation unit, index 
translation unit, security processor, etc.) [16]. 

This report does not take a position on whether the data base model 
should be network, hiearchical or relational. We think the capabilities 
of a vendor provided DBMS, in terms of dictionary, integrity, recovery, 
query language, etc. features, are more important than the particular 
model employed, although compatibility with existing COBOL programs 
would seem to argue for the CODASYL (network) approach. 

Functions of DBM Module 
1. Catalog 

Maintain the catalog of file names and status: 

- Name 

- OPEN or CLOSED 

- Si ze 

- Physical address of file 

- Physical address of index 

- Application used in 

- Date entered into system 

- Expiration date, if any 

- Location of backup copy 

- Format 

- Access restrictions 

Only files pertaining to so-called foreground applications, (i.e. , 

non-3urroughs files) will be cataloged. If a file name cannot be 
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found, the message will be forwarded to the Burroughs node (unspeci- 
fied at this time) vdiich contains the catalog for host files. 

2. Operations 

Under a menu selection scheme, perform the following functions: 

0 Retrieve a record for terminal display. 

° Change record in specified fields. 

° Delete a record 
° Insert a record 
° Print a file 
° Print a record 

In the case of printing a record, the transaction message will be 
routed by TM to DBM first. The DBM module will locate and retrieve 
the record and send it to the Peripheral Management (PM) module for 
printing. Witn regard to printing a file, TM will also send the 
transaction to DBM first, which will open the file for PM. The PM 

module will access and spool the file for printing of these onto its 

own disk file. Printing can then occur without interference on the 
LAN, since PM disks will be local to that module's processor. 

3. Dictionary 

A dictionary will be provided for the purpose of defining and 
characterizing the data elements. The dictionary should be an 

integral part of vendor supplied DBMs. The dictionary will ^erve as 
an excellent vehicle for requiring users and developers to define 

data elements in SPLICE to bring definitions up to date, discard 
outdated elements, introduce new elements, ana, in general, provide 
a method for rigorously defining data requi rements. The dictionary 
will also be of great assistance for designing screen and report 
formats, as described under Terminal Management. 
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DBMS Implementation 

Terminal Management (TM) pre-processing of the user's query or 
update transaction and the post-processing of the returned data will be 
performed in one minicomputer (the one where TM is resident) while data 
base functions (e.g., record retrieval , record update, etc.) will be 
handled in a separate minicomputer. A proposed back end data base 
management system [15,27] utilizing the aforementioned specialized file 
server approach is shown in Figure 15. For high performance purposes, 
dbns overhead functions (e.g., dictionary, catalog and index) are 
handled by a separate processor. Among its functions is to index from 
the logical key field provided by the user process to a physical disk 
address. This processor has fixed head disk files for high speed 
operation of the above functions. The actual retrieval and storage of 
records and physical storage management is performed in a second data 
base processor, which has associated with it the actual data files. 
Active files are stored on fixed head disks; less active files are 
stored on movable head disks. 
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SYSTEM CONTROL 



With the exception of Recovery Management (RM) and certain resource 
allocation functions, the various functional modules (FMs) operate as a 
distributed system. What this means specifically is the following: 

° Modules exchange messages directly without first obtaining permission 
of, or passing then through a central control, 
o FMs bid directly for the use of additional reusable resources (e.g., 
memory, fixed head disks) which may be necessary for providing 

greater workspace in order to conduct multi-tasking. Existing system 
and user files and the opening of new permanent files are not 
included in this category of resourses, being the responsibi 1 ity of 
the Data Base Management module. 

° A small Resources Allocation (RA) module assists the FMs in obtaining 
sharable reusable resources. This module is associated with the 
Resources Status Table (RST) of Figure 3. The RA, which is imple- 
mented in a dedicated processor, performs the function of shared 

resource allocation. It has availaole to it memory and fixed disk 
units which it allocates to the FMs on a shared basis. Naturally, FM 
processing which involves the use of shared resources will be slower 
per transaction than processing which uses dedicated resources 

because of transmission delays on the LAN and contention for shared 
resources. However, throughput would be increased. 

This philosophy of control is amplified further below: 

0 Each FM will respond positively to only a specified set of Services 
Request Codes (e.g., retrieve a record for the Data Base Management 
module), as indicated in Figure 7. If the module receives an invalid 
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Service Request code, it will forward the message to tne Recovery 
Management module for disposition, with an error code indicated. 

Each FM will be equipped with sufficient dedicated resources (e.g. , 
local memory) to be able to process its worst case Service Request. 
This means that a module will always be able to process at least one 
transaction, i.e. , service request. This also implies that deadlocks 
cannot occur. 

° A module only bids for the use of shared resources (See Figure 3), 
when it is presented with multiple tasks to perform and is unable to 
process them concurrently without the use of additional (shared) 
resources. The FM sends a resource request to RA, via a control 

message on the virtual "control bus", giving it the type and quantity 
of resource desired. In some cases multiple resources will be 

required. The RA module sends "grant" message to the FM if the 

resource is available in the quantity desired; RA will then subtract 
the acquired amount of resource from the available quantity of 
resource in the RST. Upon receiving a "grant" message, FM will set 
an interval timer to a system-specified maximum value. Upon the 
expiration of this interval, the FM returns the resources to the pool 
by sending a "release" message to RA. The RA module then adds the 
released resource to the quantity available in the RST. The timer 
interval length can vary among FMs, depending upon processing 
priorities, and can be set by the System Operator. An FM must bid 
again, if resources are required subsequent to tne release of 
resources . 

If the resource is not available in the desired quantity, the RA 
sends a "denied" message to the FM, which will continue to process 
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with the use of local resources only. No record is kept by RA of 
this bid, and the FM must rebid at a later time, which is determined 
by an interrupt generated by a system-specified and operator 
adjustable timer interval set by the FM. 

° AIT of the above descriptions pertain to the use of control messages 
flowing on the "virtual" control bus. Once an FM has acquired a 
resource, it will send data (file records in sane cases) to be stored 
in the resource unit and read data from the resource unit, with the 
assistance of RA. Data messages will be transferred on the "virtual 
data bus" and will be addressed to RA according to the two level 
address procedures described previously, i.e. , by the node in which 
RA resides and by the name of the RA module. In addition, RA must 
map between the message identification, as stored in a message by the 
FM, and the physical shared storage space. Upon receipt of a control 
message from the FM, giving the message identification, RA will map 
to the physical storage locations, retrieve the message and send it 

to the FM. 

Although the above "contention system" of allocating shared 

resources is crude in that resource requests are not queued, and 
requests will not necessarily be served on a FIFO basis, it has the 

great advantage of simplicity and low cost, due to the self-regulatory 
nature of the scheme. As soon as recordkeepi ng and queue maintenance 
are introduced to keep track of multiple requests - order of receipt, 
type and amount of request - the complexity rises rapidly. It is 
possible that sufficient local resources could be economically provided 
to each FM, such that an overload would rarely occur, and shared 

resources could be dispensed with entirely. 
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FUTURE WORK 



The next step in the LAM design effort is to use the functional 
design specifications, which have been provided in this report, as the 
basis for designing a simulation model, which will be used to estimate 
the performance of the LAM in terms of response time and message transit 
time operating under a variety of transaction loading distributions. 
Quantitative data which are available pertaining to types, numbers and 
rates of transaction inputs will be used to drive the simulation. 
Quantitative analysis is vital to the design effort since, at this point, 
we have a qualitative design which we feel is workable, but significant 
quantitative performance analysis is required in order to provide greater 
assurance of the validity of the concepts. 

Secondly, a mapping will be performed between the functional LAM 
design described in this report and a specific LAN physical system (i.e. , 
topology, access method, communications medium, protocols and operating 
system). This will be done in order to select that hardware and software 
system, from among the available LAM alternatives, which best realizes 
the functional design. 
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